React: Flux 是怎样工作的

原文: https://github.com/facebook/flux#how-flux-works

---

Flux 是怎样工作的

Flux 应用有三个主要的部分: Dispatcher, Store, 以及 View (React components).
这几个不应该和 Model-View-Controller 混淆.
Controller 在 Flux 里是存在的, 不过那是 Controller-View,
-- 这些 View 经常是在层级的顶端, 会从 Store 取出数据又把数据往下传给子节点.
另外, Action -- 就是 Dispacher 的辅助方法 -- 用来提供 Distacher 更语义化的 API.
可以把 Action 想象成 Flux 更些循环的第四个部分.

Flux 避开了 MVC 而选用一种单向的数据流.
当用户和 React 的 View 发生交互, View 通过中心的 Dispatcher 传播一个 Action.
发送到各个 Store, 其中容纳了应用的数据和业务逻辑, 这里的更新会影响所有的 View.
这一点在 React 声明式的编程风格当中发挥得特别好,
因为这使得 Store 能发送所有的更新, 而不用指明如何在 View 的各种状态间如何切换.

我们最初开始正确处理求出的数据, 比如我们想显示消息列表的未读数量,
同时其他的 View 显示了话题列表, 其中高亮了未读的部分. 这在 MVC 里不好处理
-- 更新一个话题为已读会更新到话题的 Model, 这样也就需要更行统计未读的 Model.
这里的依赖和串联更新在大应用中经常出现, 导致数据流交错和紊乱, 甚至难以预测.

Control 和 Store 反转过来了: Store 接收数据更新并适当调和数据,
而不是依赖外部的代码通过一致的方法来更新其数据.
Store 以外的没有办法了解里面怎么管理数据, 以此来达到业务的清晰分隔.
这也让 Store 比 Model 更好测试, 特别是因为 Store 没有 setAsRead 那样直接的 setter 方法,
而是只有一个关于负荷输入的入口, 从 Dispatcher 传送, 源于 Action.

结构和数据流

Flux 应用里的数据以单向流动, 形成和回路:

Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores -------+
Ʌ                                                                                   |
|                                                                                   V
+-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+

单向的数据流是 Flux 模式的核心, 而且实际上 Flux 的名字是从拉丁文的 flow 来的.
上边的图表当中, Dispatcher, Store 和 View 分别是独立的节点, 有明确的输入和输出.
其中 Action 是一个简单分离的, 语义化的辅助方法用来帮助传送数据到 Dispatcher.

所以数据以 Dispatcher 为中心集线器流过.
Action 主要是原子用户在 View 上的操作, 仅仅是到 Dispatcher 的一个调用.
Dispatcher 随后触发 Store 注册到上面的事件, 有效地把 Action 负载的数据分发到所有 Store.
通过他们注册的事件, Store 决定哪些 Action 是他们需要的, 然后针对他们进行响应.
Store 返回发出一个 "change" 事件提醒数据所在那层的 Controller-View.
Controller-View 监听这些事件, 并通过事件回调从 Store 获取到数据.
Controller-View 然后通过 setState() 或者 forceUpdate() 调用其 render() 方法,
更新自身以及全局子节点.

这个结构让我们能佷快在应用中查找原因, 这个办法有点怀旧像函数式响应式编程(FRP)的风格,
或者更确切说是"数据流编程"或者 flow-based programming(FBP) -- 而不存在双向绑定.
应用的状态仅仅在 Store 当中维护, 允许应用的不同部分高度地解耦.
Store 之间不存在依赖, 他们保持了严格的层级关系, 还有通过 Distatcher 同步维护的更新.

我们意识到双向绑定导致串联的更新, 一个对象改变导致另一个改变, 这还可能触发更多更新.
当应用规模增加, 这些串联的更新使得用户操作结果改变了什么很难预测.
而当更新只在单个回路上更新数据, 这个系统整体上就更容易预测了.